This forum is closed to new posts and
responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:
My Lotus Notes Christmas List - and a few more wishes ~Bill Quetfoochekakol 21.Dec.03 09:16 PM a Web browser General 6.5All Platforms
Boy, wouldn't it be nice.
I have a few additions, mostly regarding the LotusScript IDE:
Re-stating a point from the list, that would increase my productivity as a developer by 20+ percent...
12. Better visual class handling in Designer IDE (instead of displaying a class as one gigantic chunk of code in the Declarations section)
My addition: If you have multiple classes defined in a single Declarations section it is impossible keep track of where you are. If developers want to gain the advantage of Object Oriented development for the Notes Client, we have no alternative but to use LotusScript, since Java doesn't support any UI (event) API interface. And OO support (user defined classes) in the LotusScript IDE is a joke. It is 10+ years behind VB, and falling further behind year by year. If Lotus/IBM wants everyone to move to Java, then provide a comprehensive UI API interface.
... and add my two cents worth:
Make Notes client caching/loading of script libraries more efficient. Try opening a document that uses a form that calls upon 10+ script libraries over a dial-up (<64kBit) line, and you know what I'm talking about. Now try closing the document, and re-open it. Surprise! It still takes ages to load. And it isn't just a problem with slow WAN lines. My company recently performed a test to establish how to improve performance. We have developed an application development framework (LotusScript/OO-based) that naturally calls on quite a few bits of base-code, located in Script Libraries. We found that the time it takes to open a document (100Mbps LAN connection, low server load) was on the slow side, so we decided to find out why. We established that the form USEd (directly and indirectly) a total of 17 script libraries (typical for a large application I'd say). From the notesUIView.QueryOpenDocument event being triggered until the Form's Initialize event being triggered it took 1.7 seconds. This time roughly reflects the time a user has to wait from double clicking a document in a view, until the form is loaded (assuming the document itself is light-weight). By merging all the code from the 17 script libraries into one "mega"-library (approx 300K source code), we reduced the loading time from 1.7 seconds to 0.4 second. A 400%+ performance improvement!!!!
So why don't we just move all our LotusScript code into one big Script Library? Assuming we don't need to stay R5 compatible (64K source restrictions in LS Script Libraries apply in R5) we could. But it would become totally unmanagable for the following reasons:
1. It makes it impossible to structure standard libraries, and call upon them as they are needed.
2. It is impossible to assign multiple developers to a project (since they would overwrite each others code changes).
3. When you are placing all your code in user defined classes (like OOD tells you to), you end up with all code being located in one HUGE chunk of source code in a single (Declarations) section, with no navigation tools (expand/collapse Classes/Properties) provided by the IDE.
So you are left with a choice between performance and maintainability. One OR the other!
Would it be difficult for Iris/Lotus/IBM to implement? I don't think so! In the Java IDE supplied with ND6 (R5) Domino Designer, there is a Class/Method browser. So someone somewhere within the IBM organisation knows how to do it.
PLEASE, could we have it for LotusScript, too.
Now for my other wishes:
1. Allow code in script libraries to "USE" code from each other without an "Illegal circular USE" error being thrown. It is very common in OO development that classes refer to each other bidirectionally. Any object that send a reference to itself (Me) to the constructor (or any other method) of another object needs this. Currently in LotusScript this requires the two classes to be located in the same script library, or one of the classes to use late binding (Declare the other class as a Variant). The first method prevents you from doing modular, progressive design, the second prevents you from benefitting from compile time type checking.
2. Be more "permissive" when it comes to changing the signature of classes. Currently, if you change (add/remove/retype) any properties in a user defined class, any other design elements using this class need to be recompiled, and this recompile needs to be cascaded down through the USE hierachy. Not a problem as long as your code is within one database (ND6 recompile), but once you have multiple templates that do design element inheritance between them, it becomes a pain in the ****.
3. Provide (and document) the C-API interface to the database-level recompile, available in ND6 (Tools/Recompile LotusScript). This would allow me to write my own project recompiler. And no, I can't just use Damien Katz recompile code from the sandbox. You have to sort script libraries in USE-order to do design element recompile, and it becomes too much of a project in itself to re-write.
4. Provide native LotusScript interfaces to ALL facilities available in Formula Language. I see no reason why I should have to resort to Evaluate("@UserRoles") to obtain the user roles of the current user. And when it comes to UI interface @Command(), you don't even have the option of using Evaluate. Only about 50% of the @Command functions available are accessible from LotusScript.
5. Auto completion to be extended to user defined classes, rather than being restricted to native Notes* classes.
6. Provide native Source Code Control (Version control) in Domino Designer, or provide/encourage the development of third party LotusScript development tools to be integrated. What about providing Eclipse for LotusScript (not an impossible task, I'd say). Keeping track of changes made by a handful of developers in a large project is impossible as iut is. Using current third party tools such as Team Studio CIAO, isn't a solution to the problem.
I could come up with about ten more points, but it's probably going to be a waste of my time.
It seems that IBM's commitment to Notes/Domino is half-hearted. Especially when it comes to development tools for native Notes Client applications. Example: Have a look at the Style Sheet support in the Notes Client. It caters for about 20% of what you need. You can't even control the borders, margins and padding of table cells.
OK. I had the opportunity to let some steam out, and I feel better for it. Have a nice christmas everyone. My family will provide me with my christmas presents this year, and I won't hold my breath waiting for IBM/Lotus/Iris to fulful any of the above wishes next year.
Return to top
. . My Lotus Notes Christmas List - and... (~Bill Quetfooch... 21.Dec.03) 
Print this page
